﻿CRYPTEXT x64 – TECHNICAL DOCUMENTATION
======================================
Status: 0.11w fix1
Date: September 10, 2026
Product name: Cryptext x64
Internal binary names: Cryptext64.exe / Cryptext64Shell.dll
Target platform: Windows x64, classic native Win32 application
Assembler: Flat Assembler (FASM), tested with FASM 1.73.35

1. Purpose and project goals
----------------------------
Cryptext x64 is a native 64-bit file-encryption application for Windows and a
modern reimplementation of the classic Cryptext 3.4 Windows shell extension.

The project has four primary goals:

1. Modern authenticated file encryption using a documented, versioned,
   long-term readable file format.
2. A small classic Win32 user interface without .NET, WebView, or large runtime
   frameworks.
3. Windows Explorer integration through a thin native x64 COM shell extension.
4. Backward compatibility with the historical Cryptext 3.x/3.4 format for
   decryption only.

Cryptext x64 keeps the historical encrypted-file suffix:

    .$#!

The visible product name is "Cryptext x64". The internal filenames
Cryptext64.exe and Cryptext64Shell.dll are retained for technical and
compatibility reasons.


2. Current validated state
--------------------------
0.11w fix1 is the current validated stable project state.

Confirmed functionality includes:

- modern CT64FILE-v1 encryption and decryption,
- AES-256-GCM authentication and PBKDF2-HMAC-SHA-256,
- safe temporary-file / verification / commit transactions,
- multi-selection and mixed batches,
- command-line handoff and Explorer shell extension,
- double-click handling for .$#! files,
- drag & drop,
- Always on Top,
- protected virtual keyboard,
- local password vault using PIN, DPAPI, PBKDF2, AES-GCM and A/B Registry slots,
- changing the long Cryptext password stored in the vault,
- German/English switching,
- Cryptext 3.x/3.4 legacy decryption,
- modal About dialog with a hidden three-state file-icon selector.

The legacy 3.4 path has been tested in practice with real files created by
Cryptext 3.4: 0 bytes, 1 byte, 16 KiB, 16 KiB + 1 byte, 4 MiB and
4 MiB + 1 byte, plus additional small files, using two different passwords.

The modern CT64FILE-v1 reader also passed mutation tests covering altered
headers, sizes, salts, nonces, ciphertext, GCM tags, and reordered, duplicated,
or removed data records.


3. Source-code architecture
---------------------------
Important modules:

    src\Cryptext64.asm
        Main application, windows, dialog control, central UI logic,
        messages, resources and imports.

    src\fileformat.inc
        Frozen CT64FILE-v1 layout constants.

    src\fileformat_v1.asm
        Header construction/validation, nonce/AAD generation and
        file-format helper functions.

    src\crypto_cng.asm
        Windows CNG cryptographic helper functions.

    src\filecrypt.asm
        Modern file encryption/decryption and safe file transactions.

    src\legacy34.asm
        Read-only compatibility reader for Cryptext 3.x/3.4.

    src\secure_input.asm
        Protected password buffer and optional process-session cache.

    src\vkbd.asm
        Virtual QWERTZ keyboard with optional randomization.

    src\vault.asm
        Vault format, DPAPI, KDF, AES-GCM, A/B slots and vault logic.

    src\vault_ui.asm
        Modal PIN dialogs and randomized numeric on-screen keypad.

    src\vault_change_ui.asm
        Changes the long Cryptext password stored in the vault.

    src\progress.asm
        Progress window, phases, disk sync and telemetry.

    src\cmdline.asm
        Command-line parser and path staging.

    src\ui_extras.asm
        Drag & drop, system menu, Always on Top and vault menu entries.

    src\language.asm
        German/English switching and language preference.

    src\about.asm
        Modal About dialog and file-icon Easter egg.

    src\Cryptext64Shell.asm
        Thin Explorer COM extension; no passwords and no cryptography.


4. Build and runtime environment
--------------------------------
Reference build environment:

    C:\fasm\FASM.EXE
    C:\fasm\INCLUDE

Build command:

    build.bat

The project uses the standard FASM Win64 environment, including win64a.inc.
The target is a classic native PE64 GUI application.

The development/test reference platform is Windows 10 x64. The code targets
modern 64-bit Windows systems.


5. Password model and SecureInput
---------------------------------
The real long Cryptext password is not stored as plaintext in a normal Windows
EDIT control.

SecureInput uses a private 4096-byte allocation:

    0x000..0x7FF   active operation password
    0x800..0xFFF   optional process-session password

Memory is allocated with VirtualAlloc. VirtualLock is best effort; failure to
lock memory must not disable the core application.

The visible password EDIT contains bullet characters only. The actual password
is held in the private SecureInput buffer.

Maximum capacity:

    CT_SECURE_INPUT_MAX_WCHARS = 512 UTF-16 code units

Session modes:

    "Do not keep in memory"
        The session region is cleared after use.

    "Remember until Cryptext exits"
        The password is copied into the separate session region and can be
        reused for later operations.

Both active and session regions are overwritten before process shutdown.

CT64FILE v1 uses the EXACT UTF-16LE code units entered by the user:

- no terminating NUL in KDF input,
- no Unicode normalization,
- no conversion to ANSI.

Therefore modern Cryptext x64 passwords can in principle contain arbitrary
Unicode code units, including characters above U+FFFF represented as UTF-16
surrogate pairs, such as emoji.


6. Virtual keyboard
-------------------
The virtual keyboard is a separate Win32 window and writes directly to
SecureInput.

Security/design rules:

- no SendInput,
- no keybd_event,
- no synthetic WM_CHAR or WM_KEYDOWN messages,
- button/symbol ID -> direct internal SecureInput operation,
- WDA_EXCLUDEFROMCAPTURE best effort,
- multi-monitor positioning,
- sensitive labels can be hidden during specific mouse interactions,
- layout randomization uses BCryptGenRandom,
- RNG failure does not disable input; canonical QWERTZ remains usable.

The keyboard starts in normal QWERTZ order. Randomization is explicitly
user-triggered.

A hidden Unicode/emoji palette has been discussed but is NOT implemented in
0.11w fix1.


7. CT64FILE v1 – modern file format
-----------------------------------
CT64FILE v1 is frozen. Its layout must never be silently changed under the same
format version.

Cryptography:

    KDF:        PBKDF2-HMAC-SHA-256
    Cipher:     AES-256-GCM
    Key:        256 bits
    Salt:       16 bytes
    GCM tag:    16 bytes
    Writer KDF: 600,000 iterations
    Writer chunk size: 4 MiB
    Reader PBKDF2 maximum: 10,000,000 iterations
    Reader chunk range: 64 KiB to 64 MiB, power of two

Windows CNG is used for cryptographic primitives.


7.1 Fixed header, 72 bytes
--------------------------
All integer fields are little-endian unless explicitly stated otherwise.

Offset  Size   Meaning
------  -----  --------------------------------------------------------------
0x00       8   ASCII magic "CT64FILE"
0x08       2   FormatVersion = 1
0x0A       2   HeaderSize = 72
0x0C       4   Flags = 0
0x10       4   KdfId = 1 = PBKDF2-HMAC-SHA-256
0x14       4   CipherId = 1 = AES-256-GCM
0x18       4   PBKDF2 iteration count
0x1C       4   data chunk size
0x20       8   original plaintext size
0x28       4   metadata plaintext size = 48
0x2C       4   Reserved = 0
0x30      16   random salt
0x40       8   random nonce prefix


7.2 Encrypted metadata, 48-byte plaintext
-----------------------------------------
Offset  Size   Meaning
------  -----  --------------------------------------------------------------
0x00       4   MetadataVersion = 1
0x04       4   MetadataSize = 48
0x08       8   original creation FILETIME
0x10       8   original last-write FILETIME
0x18       8   original last-access FILETIME
0x20       4   restorable FILE_ATTRIBUTE_* bits
0x24       4   MetadataFlags = 0
0x28       8   Reserved = 0

Restorable basic attributes are READONLY, HIDDEN, SYSTEM and ARCHIVE.


7.3 Records, nonce and AAD
--------------------------
Record 0 is the encrypted metadata record.
Data records begin at index 1.

Every record is an independent AES-GCM operation under the same per-file
256-bit key derived from the password.

12-byte nonce:

    nonce[0..7]   = 8-byte nonce prefix from the fixed header
    nonce[8..11]  = record index as uint32 BIG-ENDIAN

80-byte AAD:

    AAD[0..71]    = exact stored 72-byte fixed header
    AAD[72..75]   = record index as uint32 little-endian
    AAD[76..79]   = record plaintext length as uint32 little-endian

Every record therefore authenticates the entire fixed header, its position and
its length. Moving or reusing an otherwise valid record at another position
causes authentication failure.


7.4 On-disk record layout
-------------------------
Immediately after the fixed header:

    48 bytes metadata ciphertext
    16 bytes metadata GCM tag

Then for each data chunk:

    ciphertext with the same length as plaintext
    16-byte GCM tag

There are no independent per-record headers.

A zero-byte file has no data records but still has an authenticated metadata
record.


7.5 Expected encrypted size
---------------------------
Let:

    H = 72
    M = 48
    T = 16
    P = plaintext size
    C = chunk size
    N = ceil(P / C), with N=0 when P=0

Then:

    encrypted_size = H + M + T + P + N*T

Truncation and unexpected trailing bytes are rejected.


7.6 Deterministic test vector
-----------------------------
Password:
    Test0815$#!

PBKDF2 iterations:
    10000 (test vector only)

Salt:
    000102030405060708090a0b0c0d0e0f

Nonce prefix:
    a0a1a2a3a4a5a6a7

Derived key:
    295851377f21a8a02f2f293f760f710ce4f724cb18a3c100ae22bca885b64ec8

Total size:
    188 bytes

SHA-256:
    a402b22d38d109669d156520bae40890e530561e30fd3d044dea504262d59558


8. Safe file transaction
------------------------
Cryptext x64 never encrypts or decrypts modern files in place.

8.1 Encryption
--------------
Conceptual flow:

    read-only source
        ->
    hidden source.ext.$#!.temp using CREATE_NEW
        ->
    write complete CT64FILE v1
        ->
    FlushFileBuffers
        ->
    close temp
        ->
    reopen temp read-only
        ->
    re-derive key from stored salt/iteration count
        ->
    authenticate/decrypt all GCM records
        ->
    byte-compare against the still untouched source
        ->
    MoveFileExW(..., MOVEFILE_WRITE_THROUGH) to source.ext.$#!
        ->
    finalize timestamps/attributes
        ->
    delete source only when "keep original" is disabled

Existing final files are never silently overwritten.


8.2 Decryption
--------------
Conceptual flow:

    encrypted source read-only
        ->
    hidden OriginalName.temp
        ->
    authenticated record-by-record decryption
        ->
    FlushFileBuffers
        ->
    second on-disk verification pass
        ->
    MoveFileExW WRITE_THROUGH to OriginalName
        ->
    restore authenticated metadata
        ->
    optionally delete .$#! source

Decryption removes only the .$#! suffix. CT64FILE v1 does not separately store
the original filename.


8.3 Error and crash behavior
----------------------------
- The source is not deleted before complete success.
- Normal handled failures remove incomplete temporary output.
- A hidden temporary file may remain after a hard process/OS crash.
- ERROR_DISK_FULL is handled.
- No secure physical erase guarantee is made for SSD/HDD media.
- Existing final names are not silently overwritten.


9. Disk sync and progress UI
----------------------------
The progress window uses three logical phases:

    0..70%    write / encrypt or decrypt + disk sync
    70..99%   on-disk verification
    99..100%  finalization

Internally, the progress bar uses 0..1000 units:

    WRITE_END  = 700
    VERIFY_END = 990

FlushFileBuffers runs in a helper thread. The UI thread waits in 50 ms slices
while pumping messages, keeping the application responsive during long flushes.

"+ Disk-Sync" has its own visible sub-state:
gray -> pulsing during flush -> black.

The progress window intentionally has no system menu, because entering a modal
Windows system-menu loop could pause work performed on the UI thread.


9.1 Telemetry
-------------
For large or slow operations, three compact lines can appear on the right:

    size
    MiB/s
    ETA + overall percentage

At 400 MiB and above, the size line is shown immediately. Throughput is updated
at most once per second and smoothed. During phase 1, ETA also includes the full
verification pass that still follows.


10. Multi-selection, batch and drag & drop
------------------------------------------
Each selected file is processed as an independent transaction.

Supported:

- Explorer/common-dialog multi-selection,
- full paths from different directories,
- mixed selection of normal and .$#! files,
- drag & drop of one or more files,
- AUTO mode: .$#! -> decrypt, everything else -> encrypt.

Folders are currently rejected by drag & drop; recursive folder processing is
not implemented.

A failure in one file does not roll back previously completed files. Processing
can continue after per-file errors.

A fully successful batch no longer displays a success summary. Error/abort/stop
summaries remain.

The summary text is version-neutral since 0.11w:

    "Multi-selection completed."


11. Command line
----------------
Supported syntax:

    Cryptext64.exe [--auto|--encrypt|--decrypt]
                   [--keep-original|--delete-source]
                   "path1" ["path2" ...]

Examples:

    Cryptext64.exe --encrypt "D:\Test\a.bin" "E:\Data\b.mkv"
    Cryptext64.exe --decrypt "D:\Test\a.bin.$#!"
    Cryptext64.exe --auto "D:\a.txt" "E:\secret.$#!"

"--" terminates option parsing.

Path arguments are copied into Cryptext-owned memory before processing.
Cryptography is not started merely by command-line invocation; the normal
password UI and user confirmation remain part of the workflow.


12. Explorer shell extension
----------------------------
File:

    Cryptext64Shell.dll

Technology:

    native x64 in-process COM shell extension
    IShellExtInit
    IContextMenu

CLSID:

    {2EDA86D0-E18E-43B4-9648-D3E4320C5FA7}

The DLL is intentionally thin:

- no passwords,
- no file cryptography,
- no vault keys,
- only selected paths, mode classification, menu UI and EXE launch.

Context menu:

    normal files       -> Encrypt      -> --encrypt
    .$#! files         -> Decrypt      -> --decrypt
    mixed selection    -> Cryptext     -> --auto

The menu commands use real colored 16/32/64-pixel bitmaps.

Mapping:

    Encrypt = closed lock with key
    Decrypt = open lock

File type:

    ProgID: Cryptext64.EncryptedFile

Double-click command:

    Cryptext64.exe --decrypt "%1"

Double-clicking does not decrypt without interaction. The normal password
workflow and confirmation are still required.


13. Per-user installation and Registry
--------------------------------------
The current test installer works per user and does not require administrator
rights.

Typical installation directory:

    %LOCALAPPDATA%\Cryptext64

Important registration:

    HKCU\Software\Classes\CLSID\
        {2EDA86D0-E18E-43B4-9648-D3E4320C5FA7}

    HKCU\Software\Classes\*\
        shellex\ContextMenuHandlers\Cryptext64

    HKCU\Software\Classes\.$#!

    HKCU\Software\Classes\Cryptext64.EncryptedFile

During an update, an already loaded shell DLL is deregistered and Explorer is
restarted when required so the in-process DLL can be replaced. A first install
does not restart Explorer unnecessarily.


14. German/English switching
----------------------------
Language preference:

    HKCU\Software\Cryptext64
        Language   REG_DWORD

Values:

    0 = German
    1 = English

Missing or invalid values default to German.

Language switching is hidden behind a deliberately unobtrusive 20x5-pixel
Easter egg in the upper-right corner of the main window. The visible area and
hitbox are both exactly 20x5 pixels.

The Explorer shell extension reads the same Registry preference dynamically,
so a language change is not intended to require an Explorer restart.


15. Password vault
------------------
The vault is a local convenience layer. It does not change CT64FILE v1 and is
NOT required to recover a .$#! file.

Primary rule:

    Files remain protected by the real long Cryptext password.
    The vault only stores that password locally in encrypted form and can
    later restore it into SecureInput.

Registry:

    HKCU\Software\Cryptext64\Vault

Production slots:

    VaultA   REG_BINARY
    VaultB   REG_BINARY


15.1 Key hierarchy
------------------
    PIN (4..6 digits)
             +
    random Salt16
             +
    random DeviceSecret32
             |
             | DeviceSecret is stored only under current-user DPAPI
             v
    PBKDF2-HMAC-SHA-256
    600,000 iterations in the current writer
             |
             v
    256-bit KEK
             |
             v
    AES-256-GCM unwraps/wraps
    random 256-bit VaultKey
             |
             v
    AES-256-GCM protects
    the real long Cryptext password

The 32-byte DeviceSecret is generated with BCryptGenRandom.
CryptProtectData/CryptUnprotectData are used without LOCAL_MACHINE scope, so the
protection is bound to the current Windows user.

Registry contents are treated cryptographically as public/untrusted storage.


15.2 PIN
--------
The user chooses any PIN containing 4 to 6 decimal digits. There is no separate
fixed 4/5/6-length selector; every length in the permitted range is accepted.

The real PIN is not stored as text in standard EDIT controls. Those controls
display bullets only; the input resides in private vault buffers.


15.3 Randomized PIN keypad
--------------------------
The PIN dialog can open a separate on-screen numeric keypad.

- digits 0..9 are shuffled on every open,
- RNG: BCryptGenRandom,
- clicks write directly to the internal PIN buffer,
- no synthetic keyboard events,
- preferred position: right of the PIN dialog, then left, below, above,
- position is clamped to the nearest monitor work area.


15.4 Vault blob v1
------------------
Magic:

    "VLT1"

Fixed header:

    0x90 bytes

Maximum blob size:

    4096 bytes

Layout:

    [0x90-byte header]
    [DPAPI(DeviceSecret32), variable length]
    [WrappedVaultKey, exactly 32 bytes]
    [EncryptedCryptextPassword, UTF-16LE, no NUL]

Header fields:

Offset  Size   Meaning
------  -----  --------------------------------------------------------------
0x00       4   Magic "VLT1"
0x04       4   Version = 1
0x08       4   HeaderBytes = 0x90
0x0C       4   TotalBlobBytes
0x10       8   Generation
0x18       4   Flags = 0
0x1C       4   KDF ID = 1
0x20       4   KDF iteration count
0x24       4   Cipher ID = 1
0x28       4   DPAPI blob offset
0x2C       4   DPAPI blob length
0x30       4   WrappedVaultKey offset
0x34       4   WrappedVaultKey length = 32
0x38       4   password ciphertext offset
0x3C       4   password ciphertext length
0x40      16   public KDF salt
0x50      12   GCM nonce for VaultKey wrapping
0x5C      16   GCM tag for VaultKey wrapping
0x6C      12   GCM nonce for password encryption
0x78      16   GCM tag for password encryption
0x88       8   Reserved = 0


15.5 A/B slot rule
------------------
VaultA and VaultB provide crash/power-loss safety, not an extra cryptographic
factor.

A Generation value may participate in slot selection only after the slot has
successfully completed:

1. structural parsing,
2. DPAPI unprotect,
3. PIN PBKDF2,
4. VaultKey GCM authentication,
5. password GCM authentication.

Update sequence:

1. fully authenticate the current valid slot,
2. create generation = old + 1,
3. write a complete new blob to the opposite slot,
4. read the slot back from Registry,
5. byte-compare and perform complete cryptographic authentication,
6. only then consider the new generation committed.

The previous valid slot is not overwritten first.


15.6 "Change password..."
-------------------------
The main "Change password.." button does NOT re-key files that were already
encrypted.

It changes only the long Cryptext password stored in the local vault.

Flow:

    authenticate vault PIN
        ->
    enter new long Cryptext password + confirmation
        ->
    write new vault generation to opposite A/B slot
        ->
    readback + full authentication
        ->
    new password becomes current SecureInput content

Files already encrypted continue to require the password with which they were
originally created.

The dialog is clamped to the monitor work area. Bullet fields explicitly move
the caret/selection to the end after display updates.


15.7 Vault retry lockout not yet implemented
--------------------------------------------
A persistent wrong-PIN delay has been discussed as the next vault-hardening
step, but it is NOT implemented in 0.11w fix1.

Planned concept:

- temporary lock after several wrong PIN attempts,
- exponentially increasing delay,
- persistent lock state so simply restarting Cryptext is not enough.

This is primarily intended to prevent rapid PIN guessing through the local
Cryptext UI, not to replace the cryptographic DPAPI/PIN design.


16. Cryptext 3.x/3.4 legacy support
-----------------------------------
The legacy path is DECRYPT-ONLY.

Cryptext x64 never creates new RC4/SHA-1 files.

Detection:

    file begins with "CT64FILE"
        -> modern CT64FILE-v1 reader
    otherwise
        -> possible Cryptext 3.x/3.4 legacy path


16.1 Legacy file layout
-----------------------
    [RC4 ciphertext of original file]
    [12 bytes per-file data]
    [20 bytes password check]

Total size:

    original_size + 32

The historical writer created the 12-byte value from:

    8-byte FILETIME
    4 bytes from _rand()

It is used as key-diversification material.


16.2 Legacy password and SHA-1
------------------------------
The historical password dialog used ANSI.

Cryptext x64 converts the current UTF-16 password through the current Windows
ANSI code page and computes:

    passwordHash = LegacySHA1(ANSI password bytes)

Password check:

    check = LegacySHA1(passwordHash || ASCII "Cryptext")

RC4 key:

    rc4Key = LegacySHA1(passwordHash || perFileData12)

Important compatibility detail:

The original Cryptext SHA-1 code stores the five 32-bit digest words in native
little-endian memory order. Windows CNG returns the conventional SHA-1 byte
sequence. Therefore Legacy34_SHA1 performs BSWAP on each of the five DWORDs
after BCryptFinishHash.

This byte-order correction was essential to the empirically validated Cryptext
3.4 compatibility.


16.3 Legacy RC4
---------------
The RC4 key is 20 bytes.

Historical file I/O uses 0x4000-byte blocks:

    16 KiB

RC4 state continues across block boundaries.


16.4 Legacy integrity limitation
--------------------------------
The 20-byte trailer validates the password material, NOT the entire ciphertext.

The legacy format therefore has no modern whole-file MAC/AEAD guarantee.
A damaged legacy file cannot provide the same integrity assurance as CT64FILE v1
with AES-GCM.

Cryptext x64 still applies the modern safe file-transaction policy:
read-only source, hidden temp output, flush, second deterministic
decrypt/byte-compare pass, WRITE_THROUGH rename, and only then optional deletion
of the old .$#! source.


17. About dialog and file-icon Easter egg
-----------------------------------------
Since 0.11w, "Info" opens a real modal Win32 dialog
(DialogBoxIndirectParamW / DLGTEMPLATE), not a MessageBoxW.

Layout:

    icon at upper left
    short About text on the right
    flat OK button

German:

    Entwickelt von
    NotCompatible (Basti) + GPT-5.6 Sol

    Erstellt mit FASM

English:

    Developed by
    NotCompatible (Basti) + GPT-5.6 Sol

    Built with FASM


17.1 Easter egg
---------------
Clicking the visible About icon cycles:

    key -> AES v2 -> AES v3 -> key -> ...

There is deliberately no tooltip or visible instruction.


17.2 Registry and Explorer icon
-------------------------------
Preference:

    HKCU\Software\Cryptext64
        FileIconVariant   REG_DWORD

Values:

    0 = classic Cryptext x64 key
    1 = AES file icon v2
    2 = AES file icon v3

File type:

    HKCU\Software\Classes\Cryptext64.EncryptedFile\DefaultIcon
        (Default) = <Cryptext64.exe>,0|1|2

After a change Cryptext calls:

    SHChangeNotify(SHCNE_ASSOCCHANGED, ...)

Explorer is not terminated or restarted for this icon change.

EXE icon resource groups:

    #1 = variant 0
    #2 = variant 1
    #3 = variant 2

0.11w fix1 corrected STM_SETIMAGE to 0x0172 and changed the OK button to
BS_FLAT.


18. Security model
------------------
Cryptext x64 primarily protects files at rest, during transport, and when a
locked/offline storage device is lost.

Modern files provide:

- AES-256-GCM,
- authenticated header/AAD,
- independently authenticated records,
- random salt and nonce prefix,
- PBKDF2,
- no in-place encryption,
- full on-disk verification before commit.

The local vault provides:

- Registry is not treated as secret,
- random 256-bit DeviceSecret,
- current-user DPAPI,
- PIN as a real KDF input,
- random VaultKey,
- two AES-GCM layers,
- A/B updates with readback verification.

No security guarantee is made against:

- a compromised active Windows session,
- administrator/SYSTEM/kernel malware,
- privileged debuggers,
- malware with access to the Cryptext process memory,
- cameras or external observation of the screen,
- a fully attacker-controlled already-unlocked system.

VirtualLock and WDA_EXCLUDEFROMCAPTURE are best-effort hardening measures, not
absolute security boundaries.


19. ADS / Zone.Identifier
-------------------------
CT64FILE v1 does not store NTFS Alternate Data Streams inside the container.

In particular, Zone.Identifier / Mark-of-the-Web is deliberately not restored.

Other ADS are also outside v1. The current implementation therefore makes no
lossless-ADS guarantee.

A possible later ADS strategy has been discussed, but it is not part of the
frozen CT64FILE-v1 format.


20. Recoverability and format stability
---------------------------------------
Central design rule:

A .$#! file must not permanently depend on the local vault, Registry, DPAPI,
Explorer shell extension, or a particular Cryptext installation.

For CT64FILE v1, recovery fundamentally requires:

    encrypted file
    +
    real long Cryptext password
    +
    compatible reader

The vault is only a convenience layer.

A minimal portable CryptextDecrypt.exe is planned for the future:

- decryption only,
- no shell dependency,
- no vault/Registry/DPAPI requirement,
- read all published modern CT64FILE versions,
- support Cryptext 3.x/3.4 decrypt-only.

That recovery executable is not yet implemented in 0.11w fix1.


21. Known open items
--------------------
Not implemented or not yet fully implemented:

- persistent vault wrong-PIN lockout/delay,
- standalone CryptextDecrypt.exe recovery application,
- free-space preflight before large transactions,
- formally defined safe alternate-volume %TEMP% staging when source volume is full,
- full vault management such as change PIN / delete or reset vault,
- explicit "clear cached passwords" command,
- recursive folder processing from the shell,
- lossless ADS support,
- optional hidden Unicode/emoji virtual-keyboard palette,
- final installer/uninstaller polish and additional DPI work.

These items must not be documented as existing functionality.


22. Invariants for future development
-------------------------------------
1. CT64FILE v1 remains unchanged.
2. File-format changes require a new format version.
3. New files are never written using legacy RC4/SHA-1.
4. Legacy support remains decrypt-only.
5. The Explorer DLL remains free of passwords and cryptography.
6. The source is never deleted before complete success.
7. Final targets are never silently overwritten.
8. Vault/DPAPI must never be required to recover modern files.
9. Optional UI/security hardening must not make the core file path unusable.
10. Cryptographic primitives use Windows CNG/DPAPI; no custom AES/GCM/RNG.
11. CT64FILE-v1 passwords remain exact UTF-16LE code units without Unicode
    normalization.
12. Vault A/B Generation values are considered only after complete
    cryptographic authentication.


23. Recommended regression testing
----------------------------------
After changes to security-sensitive modules, at minimum:

Modern CT64FILE v1:
- 0 bytes
- 1 byte
- 4 MiB
- 4 MiB + 1 byte
- multiple records, e.g. 8 MiB + 1 byte
- wrong password
- header/ciphertext/tag mutation
- truncation and trailing bytes
- keep source / delete source
- batch and cancellation
- slow disk sync

Legacy:
- 0 bytes
- 1 byte
- 16 KiB
- 16 KiB + 1 byte
- 4 MiB
- 4 MiB + 1 byte
- at least two different ASCII passwords
- wrong password

Vault:
- setup with 4/5/6-digit PIN
- wrong PIN
- restart and unlock
- A/B readback
- change stored long password
- verify old encrypted files still require their original password

Shell/UI:
- Encrypt/Decrypt context menu
- double-click
- drag & drop
- German/English
- About icon 0 -> 1 -> 2 -> 0
- Explorer icon refresh
- flat buttons and multi-monitor clamping


24. Final note
--------------
Cryptext x64 0.11w fix1 combines a modern authenticated, transaction-safe
CT64FILE-v1 path with a deliberately separate decrypt-only legacy reader for
historical Cryptext 3.x/3.4 files.

The central compatibility principle is:

    Modern security for new files,
    while retaining readable access to old Cryptext files.

The central recovery principle is:

    The real long password plus the .$#! file must be sufficient;
    the local convenience vault must never become a permanent recovery
    dependency.
